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Abstract 

The manual application of formal methods in system 
specification has produced successes, but in the end, de- 
spite any claims and assertions by practitioners, there is 
no provable relationship between a manually derived sys- 
tem specification or formal model and the customer’s orig- 
inal requirements. Complex parallel and distributed sys- 
tems present the worst case implications for today 's dearth 
of viable approaches for achieving system dependability. 
No avenue other than formal methods constitutes a seri- 
ous contender for resolving the problem, and so recognition 
of requirements-based programming has come at a critical 
juncture. We describe a new, NASA-developed automated 
requirements-based programming method that can be ap- 
plied to certain classes of systems, including complex par- 
allel and distributed systems, to achieve a high degree of 
dependability. 
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1. Introduction 

The inherent complexity in building highly-dependable 
parallel and distributed systems is well known. As we build 
more and more sophisticated applications with more strin- 
gent timing constraints, the difficulties continue to rise in 
measure with the complexity, despite the best efforts of the 
research and development community to address means of 
tackling the problem. Expectations for dependability, effi- 
ciency, performance, maintainability and cost-effectiveness 
over a system’s entire life cycle cannot be lowered, and in- 
deed are seen to rise from any given level achieved in the 
past. Consequently, the combined effect of increasing sys- 
tem complexity and rising expectations suggests that a crit- 
ical need has arisen for a new way to resolve this issue. 
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Requirements-Based Programming (RPB) has been ad- 
vocated as a means, perhaps the only means, of developing 
highly dependable complex systems that can be guaranteed 
to be correct [2, 3]. We present Requirements-to-Design-to- 
Code, a NASA-developed approach to Requirements-Based 
Programming, which has the distinct advantage of offering 
a fully formal underpinning. The approach has been demon- 
strated to have applicability in a variety of domains. 

2. Requirements-Based Programming 

Requirements-Based Programming effectively extends 
Model-Based Development (MBD) by adding a “front- 
end”. While MBD holds that code-generation can be ef- 
ficient and practical from an appropriate model, RBP ad- 
dresses the adequate development of that model, by ensur- 
ing a direct mapping from requirements through to specifi- 
cation and modeling. 

RBP, therefore, affords the systematic and mechanical 
transformation of requirements into executable code. While 
this is an obvious goal of system development, other ap- 
proaches (including the manual application of formal speci- 
fication to derive a system model) have failed to address the 
entire lifecycle and ensure that generated code does in fact 
match the requirements [5, 6], 

As we will describe in Section 3, we have found it to have 
a number of interesting applications in verification and val- 
idation, as well as in system development ab initio. 

2.1. R2D2C 

Requirements-to-Design-to-Code (R2D2C) is the provi- 
sional name for a NASA technology that provides a mathe- 
matically tractable round-trip engineering approach to sys- 
tem development. 

In this approach, engineers (or others) may write speci- 
fications as scenarios in constrained (domain-specific) nat- 
ural language, or in a range of other notations (including 


UML use cases). These will be used to mechanically derive 
a formal model (Figure 1 ) that is guaranteed to be equivalent 
to the requirements stated at the outset, and which will sub- 
sequently be used as a basis for code generation. The for- 
mal model can be expressed using a variety of formal meth- 
ods. Currently we are using CSP, Hoare's language of Com- 
municating Sequential Processes [8], which is suitable for 
various types of analysis and investigation, and as the ba- 
sis for fully formal implementations, as well as for use in 
automated test case generation, etc. 

2.2. Formal Requirements-Based Programming 

R2D2C is unique in that it allows for full formal devel- 
opment from the outset, and maintains mathematical sound- 
ness through all phases of the development process, from 
the requirements capture stage to the automatic code gen- 
eration phase [11]. Applicable to the class of system whose 
behavior can be described as a set of scenarios, the approach 
may also be used for reverse engineering, that is, in retriev- 
ing models and formal specifications from existing code. 
The approach can also be used to “paraphrase” (in natural 
language, etc.) formal descriptions of existing systems. 

The R2D2C approach involves a number of phases, 
which are reflected in the system architecture described in 
Figure 1 . The following describes each of these phases. 

D1 Scenarios Capture: Engineers, end users, and others 
write scenarios describing intended system operation. 
The input scenarios may be represented in a con- 
strained natural language using a syntax-directed ed- 
itor, or may be represented in other textual or graphi- 
cal forms. 

D2 Traces Generation: Traces and sequences of atomic 
events are derived from the scenarios defined in D1 . 

D3 Model Inference: A formal model, or formal specifica- 
tion, expressed in CSP is inferred by an automatic the- 
orem prover — in this case, ACL2 [9] — using the traces 
derived in phase 2. A deep 1 embedding of the laws of 
concurrency [4] in the theorem prover gives it suffi- 
cient knowledge of concurrency and of CSP to perform 
the inferencing. The embedding will be the topic of a 
future paper. 

D4 Analysis: Based on the formal model, various analy- 
ses can be performed, using currently available com- 
mercial or public domain tools, and specialized tools 
that are planned for development. Because of the na- 
ture of CSP, the model may be analyzed at different 


I “Deep" in the sense that the embedding is semantic rather than merely 
syntactic. 


levels of abstraction using a variety of possible imple- 
mentation environments. This will be the subject of a 
future paper. 

D5 Code Generation: The techniques of automatic code 
generation from a suitable model are reasonably well 
understood. The present modeling approach is suitable 
for the application of existing code generation tech- 
niques, whether using a tool specifically developed for 
the purpose, or existing tools, or converting to other 
notations suitable for code generation (e.g., converting 
CSP to B and then using the code generating capabili- 
ties of the B Toolkit). 

It should be re-emphasized that the “code” generated 
may be code in a high-level programming language, low- 
level instructions for (electro-) mechanical devices, natural- 
language business procedures and instructions, or the like. 

23. Short-cut R2D2C 

The approach described in Section 2.2 is the way that 
R2D2C is intended to be applied, from requirements spec- 
ification through code generation. The approach, however, 
requires significant computing power in the form of an au- 
tomated theorem prover performing significant inferences 
based on traces input and its “knowledge” of the laws of 
concurrency. While this is well warranted for certain appli- 
cations, it is likely to be beyond the resources of many de- 
velopers and organizations. As a practical concession, we 
also define a reduced version of R2D2C called the “short- 
cut version” (Figure 2), whereby the use of a theorem prover 
is avoided, yet without sacrificing high confidence in the va- 
lidity of the approach. The following describes each of the 
phases for the shortcut R2D2C: 

51 Scenarios Capture: As before, intended system behav- 
ior is described by scenarios input in natural language, 
or an appropriate graphical or semi-formal notation. 

52 Translation to Intermediate Notation: Scenarios are 
translated to an intermediate notation, termed EzyCSP, 
which is a simple natural language-like subset of CSP 
that can be used to describe a large number of situa- 
tions and scenarios (recall that scenarios are domain 
specific). 

53 Analysis: While far more simple than CSP, EzyCSP al- 
lows some simple analyses to be performed. 

54 Implementation in Java: EzyCSP is sufficiently simple 
that it may easily be translated to Java and executed. 

This simplified or shortcut approach clearly has signif- 
icant disadvantages when compared to our full approach. 
First, the correctness of the development process is contin- 
gent on the correctness of both the translation of scenarios 
to the intermediate (EzyCSP) notation and the translation of 




Figure 1. The entire process with D1 through D5 illustrating the development approach and R1 
through R4 the reverse engineering. 


EzyCSP to Java. However, the correctness of the translators 
for these is assured via a proof of correctness undertaken 
with the ACL2 theorem proven Second, we do not have a 
reverse process, suitable to support reverse and (ultimately) 
re-engineering, for free; however, a Java-to-EzyCSP trans- 
lator would certainly be possible for highly constrained sub- 
sets of Java. 

The significant advantage of this simplified approach, 
however, is that although a proof of correctness involving 
a theorem prover is still required, this is required exactly 
once and would be performed by the support system devel- 
opers (presumably expert in the art). This is significantly 
less expensive computationally than using a theorem prover 
in the development of each individual application. 



Figure 2. Short cut R2D2C. 


3. Application Areas 

The motivation for this work was the need for automatic 
code generation for ultra-high dependability systems, but 
the method described in this paper has a broad range of ap- 
plicability. 

We have developed a prototype tool to support the 
R2D2C approach [10, 12] and have successfully ap- 
plied it in a range of areas: 

MultiAgent Systems: We have successfully under- 
taken the redevelopment of a prototype NASA sys- 
tem to automate the “lights out” (untended) operation 
of a ground control system. The system had pre- 
viously been formally specified and checked by 
hand. Our R2D2C tool successfully found all the er- 
rors that we detected by hand, and additionally found 
a number of undetected errors, all in a matter of sec- 
onds [10]. 

Wireless Sensor Networks: An application of the ap- 
proach to the development of highly dependable wire- 
less sensor networks is detailed in [7]. 

Robotic Operations: We have been experimenting with 
generating code to control robotic devices. Perhaps 
more interesting is the use of this approach to in- 
vestigate the validity and correctness of procedures 
for complex robotic assembly or repair tasks involv- 
ing multiple robots and interacting parallel processes. 
We have begun exploratory work in this direction, 
to validate procedures from the Hubble Robotic Ser- 
vicing Mission (HRSM) — for example, verification of 
the procedures for replacement of a wide-field cam- 
era on the Hubble Space Telescope (HST) is described 
in [11]. 










R2D2C: HST Example Three. 
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Compile 


Natural Language Input Ftequirements Design Code Testing 

Transaction boltrelease = new Transaction^); 

Transaction brakeset= newTransaction(2); 

Transaction stabilize = new Transaction^); 

Transaction wfctoolaquire = new Transaction^); 

GA GA_i n it = new GA(b rake set); 

DRone DRone_init= new DRone(boltrelease, brakeset, stabilize); 

DRtwo DRtwo_init= new DRtwo(boltrelease, brakeset, wfctoolaquire); 
DRoneJnit.startO; 

DRtwoJnit.startQ; 

GAJnit.startO; 

EXECUTING: 

brakeset 

brakeset 

DEADLOCK DETECTED!! 


Figure 3. Application of R2D2C prototype tool to example robotic repair procedure, showing detec- 
tion of deadlock. 


4. An Example 

To illustrate the capability of the R2D2C method using 
the prototype tool, we have selected an example procedure 
from HRSM for the replacement of a wide-field camera on 
the Hubble Space Telescope (HST). 

This example procedure, one of many possible varia- 
tions for replacing the camera, was modified to intentionally 
include an error for purposes of demonstrating the error- 
detection capability of our prototype tool. 

Figure 3 shows an execution fragment from a run of the 
tool, in which the tool has produced a message indicating 


the example procedure leads to a deadlock condition. While 
this error was detected by running the Java program pro- 
duced automatically by the tool, the formal model generated 
automatically by the tool can be subjected to automated the- 
orem proving techniques to detect the same error, as well as 
many others. 

The importance of this procedure verification capabil- 
ity looms large when it is recognized that no other tool or 
method can mechanically and automatically transform nat- 
ural language requirements into a mathematically equiva- 
lent formal model and analyze that model for errors. 

While procedure verification is an important area of ap- 









plication of the R2D2C method, the more general area of 
software verification and requirements validation is targeted 
for application of an expanded prototype tool. Additional 
future work will include expanding the error-detection ca- 
pability, incorporating theorem-proving relative to the for- 
mal model generated by the tool from the user’s require- 
ments expressed in natural language. 

5. Conclusions 

The development of complex parallel and distributed 
systems continues to pose difficulties and challenges. These 
will continue to grow unless we develop better means of 
controlling the complexity inherent in such systems and/or 
develop new techniques that will allow us to ensure that im- 
plementations truly meet requirements and allow for formal 
analysis and formal proof. Without a formal underpinning, 
such analysis and proof is impossible [ 1 ]. 

Requirements-Based Programming has been rec- 
ommended as an approach that will lead to improved 
system quality, particularly in complex applications in- 
volving significant amounts of concurrent processing. 
R2D2C is the provisional name of a NASA approach to 
Requirements-Based Programming, which not only has au- 
tomated (prototype) tool support, but also is fully formal, 
giving greater levels of confidence in the correctness of par- 
allel and distributed systems. 
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